NetWare SNA Links v1.0
Rules of Thumb 
September 29, 1992

NetWare SNA Links software works with NetWare for SAA to route IPX/SPX
protocols over an existing SNA network.  This document contains information
to aid you in configuring SNA Links for optimal performance and
reliability.  Specific topics covered include LAN and host requirements,
supported topologies, tuning tips, Things to Watch Out For, and third party
software.

What Is SNA Links?
NetWare SNA Links resides on a NetWare v3.11 server alongside NetWare for
SAA.  SNA Links uses NetWare for SAA for its underlying connectivity to the
SNA network and supports either Synchronous Data Link Control (SDLC) or
token ring connections to the SNA network.  You can use SNA Links and
NetWare for SAA to provide concurrent access to remote LAN resources and
host resources.

SNA Links is ideal for users who have multiple remote office locations and
an existing SNA network connection to each office.  With SNA Links,
customers can use their existing SNA network connections to build a
LAN-to-LAN internetwork that supports remote administration, network
management, electronic mail, and file transfer. 

SNA Links is most appropriate for LAN-to-LAN interconnections that are used
primarily for network management and non-real-time store-and-forward
applications.  If your primary application is file transfer, you should
evaluate whether the line speeds and throughput of your SNA network
connections can support the level of file transfer activity you anticipate. 
As the frequency and size of file transfers increase, the performance
constraints imposed by low-speed SNA connections, typically 9.6 Kbps or
19.2 Kbps, will become more significant.

NetWare SNA Links Requirements
Requirements for NetWare SNA Links can be divided into two categories: LAN
requirements and host requirements.  The following sections describe the
requirements for each environment.

LAN Requirements
   - A NetWare v3.11 server running NetWare for SAA v1.2 or greater. 
   - A physical link to the SNA network.  This connection can be either
   SDLC or token ring.

Host Requirements
   - A Physical Unit (PU) 2.1 node and an independent Logical Unit (LU)
   defined for each SNA Links server.
   - The appropriate Virtual Telecommunications Access Method (VTAM),
   Network Control Program (NCP), or other software for your specific type
   of host connection:

SNA Links Server Attachment    
To a front-end processor via an SDLC or token ring connection
   Host Software Required
       - NCP on a 3720 must be at least v5.2.
       - NCP on a 3725 must be at least v4.3.
       - NCP on a 3745 must be at least v5.2.
       - VTAM for either MVS or VM must be at least v3.2.

Downstream from a 3174 controller that is attached to a front-end processor
   Host Software Required
       - NCP on a 3720 must be at least v5.2.
       - NCP on a 3725 must be at least v4.3
       - NCP on a 3745 must be at least v5.2.
       - VTAM for either MVS or VM must be at least v3.2.
       - The 3174 must use either Configuration B, revision 4.0, and RPQ
       8Q0880or Configuration C.

SNA Links Server Attachment
Downstream from a 3174 controller that is attached to the mainframe via a
channel connection
   Host Software Required
       - VTAM for MVS must be at least v3.4.
       - VTAM for VM must be at least v3.3.
       - The 3174 must use either Configuration B, revision 4.0, and RPQ
       8Q0880or Configuration C.
Downstream to a 9370 via an SDLC or token ring connection
   Host Software Required
       - Any version of Telecommunications Control Subsystem may be used.
       - VTAM must be at least v3.3.
To an AS/400 via an SDLC or token ring connection
   Host Software Required
       - OS/400 v2, Release 1.1, must be used.

Configuration Note
Although the SNA Links Administration Guide states that any SNA Links
server connected downstream from a 3174 controller must use 3174
Configuration B, SNA Links also works with 3174 Configuration C.  Because
there are definition differences between Configuration C and Configuration
B, you should consult your system programmer for specific information on
your 3174 controller, VTAM, and NCP configurations.

Supported Topologies
With SNA Links, the number of remote locations that can be connected
through an SNA network is limited only by the physical resources of the
network and the performance requirements of the applications being used.
Any single NetWare SNA Links server can directly connect to 60 other SNA
Links servers in an interconnected topology.  If an internetwork requires
more than 60 direct connections, a cascaded topology is required.

Interconnected Topology
With an interconnected topology, every SNA Links server is connected to all
other SNA Links servers in the internetwork via logical paths. Since there
is a direct logical connection between all SNA Links locations,
internetwork traffic does not pass through intermediate SNA Links servers. 

The interconnected topology is the best-performing topology and should be
used as long as the number of simultaneously active SNA Links connections
does not exceed 60 for any given SNA Links server.  The following figure
illustrates an interconected toplogy (because of the inadequacies of ASCII
drawings the lines appear broken). 

             Logical Links
Server A O-------------------O Server C
         | \               / |
         |   \           /   |
         |     \       /     |
         |       \   /       |
         |         \         |
         |       /   \       |
         |     /       \     |
         |   /           \   |
         | /               \ |
Server B O-------------------O Server D
       
             
Cascaded Topology
To extend IPX/SPX routing beyond 60 remote locations, you must establish a
second level of intermediate SNA Links servers.  This type of topology is
referred to as a cascaded topology.  With a two level cascaded topology,
you can connect up to 3540 (60 x 59) LANs.  The following figure
illustrates the topology for a two level cascaded internetwork.

              Server A_____________________ Server D
                 O                             O
                 /\                            /\
                /   \                         /  \
               B     C                       E    F 
With a cascaded topology, two or more intermediate servers are connected
via logical paths.  Each intermediate server is then directly connected to
a second level of servers in the internetwork.  A server at the lower level
of the cascaded internetwork uses one or more intermediate servers to pass
data to another server in the internetwork.  For example, in the preceding
illustration, servers A and D are intermediate servers.  By using the
A-to-D connection, servers B and C can access servers E and F without being
directly connected to them.  In this manner, IPX/SPX routing is extended
beyond 60 remote locations.

Performance Guideline
If you use a cascaded topology, you will notice a decrease in response
time. The decrease varies with the application.  Response time may decrease
significantly if you are transferring files via SNA Links connections.
However, decreases in response time may be minor if you are remotely
managing a network or transferring electronic mail.

Performance Information
The following tables show the average file transfer times that Novell
obtained using SNA Links.  One set of file transfer times was obtained with
a configuration using two SDLC connections from each server attached to a
3745-170 front end processor.  The 3745-170 front end processor was then
attached to an ES/9000 mainframe.  With this configuration, only the 3745
front end processor handled the SNA traffic.  The SNA traffic did not flow
through the mainframe central processing unit.  Another set of file
transfer times was obtained with a configuration using token ring
connections from each server attached to an AS/400 Model 9406-B30.  With
the AS/400 configuration, the AS/400 processing unit handled the SNA
traffic.

The servers used in the testing were CUBIX LAN Central Station 1000 486/33
servers with NetWare NE 2000 LAN Adapters.  A Novell NetWare for SAA
Synchronous Adapter configured for 56 Kbps, 19.2 Kbps, and 9.6 Kbps was
used in the mainframe configuration.  An IBM Token Ring 16/4 host adapter
configured for 4 Mb was used for the AS/400 configuration.  The workstation
used in the testing was a COMPAQ Deskpro 386/25e with a NE2000 LAN Adapter.
The file transfer times were measured using the DOS COPY utility.

Mainframe Configuration
Novell obtained the following set of file transfer times using two SDLC
connections to a 3745-170 front end processor attached to an ES/9000
mainframe.  The times are shown in hours:minutes:seconds.milliseconds.

File Size      100KB        300KB        1MB           5MB
Average Time At 56 Kbps    
               00:00:25.00  00:01:11.25  00:03:37.34   00:17:43.47

Average Time At 19.2 Kbps
               00:01:06.30  00:03:04.25  00:09:38.30   00:48:31.10

Average Time At 9.6 Kbps
               00:02:21.20  00:06:17.18  00:19:31.50   01:37:35.12

AS/400 Configuration
Novell obtained the following set of file transfer times using token ring
connections to an AS/400 Model 9406-B30.  
File Size      100 KB       300 KB       1 MB           5 MB
Average Time   00:14.53     00:43.61     02:20.73       12:08.66

Tuning SNA Links 
Performance tuning is a major consideration with SNA Links.  
The following sections contain performance tuning information.

Pacing
You should use the highest SNA network pacing value permissible for your
host environment.  Novell has found that increasing the pacing from 2 to 63
provides a 10 percent increase in performance.  You can obtain faster
transmission by setting the pacing to zero (or no pacing), but a zero
setting requires extensive tuning of the available SNA network buffer
space.

IPX Packet Size, SNA RU Size, and Data Link Frame Size Considerations
There are three areas where size affects performance:
   IPX/SPX packet size
   SNA request unit (RU) size
   Data link frame size
Performance is increased if the entire IPX/SPX packet can be encapsulated
within a single RU within a single SNA frame.  The size of the IPX/SPX
packet is 576 bytes. SNA frames generated by SNA Links include the IPX/SPX
packet plus SNA related overhead, resulting in SNA frames of approximately
700 bytes.  To accommodate the SNA frame size, the default RU size is 768
bytes.

For token ring connections, the data link frame size is usually large
enough for NetWare SNA Links frames.  Increasing the IPX/SPX packet size
improves SNA Links' performance.

For SDLC connections, the limiting factor is the SDLC frame that has a
maximum size of 521 bytes. Whenever possible, set the MAXDATA parameter in
VTAM to 521 to increase the SDLC frame size.

Using the Packet Burst NLM with SDLC Connections
When using SDLC connections running at 19.2 Kbps or slower, you must
increase the packet burst minimum write transport delay timeout value in
the Packet Burst NetWare Loadable Module (NLM) to avoid excessive
retransmission of write type transfers.

To increase the packet burst minimum write transport delay timeout value,
you must add the following SET command from the system console of every SNA
Links server:
set minimum packet burst write timeout delay = x
The value for x can range from 0.3 to 4.9 seconds. Novell recommends
setting the packet burst minimum write transport delay timeout value to at
least 3.0 seconds for SDLC connections running at 19.2 Kbps or slower.

OTHER PERFORMANCE TIPS
The following tips may apply to your NetWare SNA Links topology.

Performance Tip 1
If you are defining an SAA service profile for an SDLC attachment for a
leased line point-to-point connection or a null modem connection, Novell
recommends that you set the Hold Request to Send (RTS) Continuously
parameter to Yes. When this parameter is set to Yes, the SDLC driver holds
the RTS high all the time, providing faster communication line turnaround
between the server and the remote host.
Do not set the RTS Continuously parameter to Yes for multidrop connections.
Setting RTS Continuously to Yes for multidrop connections prevents other
links from connecting.

Performance Tip 2
You can improve file transfer performance by setting the BUFFERS parameter
in your workstation's CONFIG.SYS file to the appropriate setting for your
hard drive.  If you are using DOS 5.0, you can further optimize file
transfer performance by specifying a secondary set of lookahead buffers.
Refer to the appropriate DOS or DR DOS document for BUFFERS parameter
information.

Performance Tip 3
When you want to administer or access data on a remote server, run a copy
of the application or utility on the local server rather than on the remote
server.  Using remote login to access and execute programs located on a
remote server results in performance delays because the executable program
or utility must be transferred across the internetwork at the local server
before execution begins. 
To avoid performance delays, log in to the local server and invoke the
desired application or utility.  Then, from within the utility, select the
appropriate remote server. 
For improved performance, you may want to take advantage of NetWare Access
Services to access data intensive applications, such as database
applications, remotely across SNA Links connections.

Performance Tip 4
You can improve file transfer performance by compressing your files with a
file compression utility before transferring them over an SNA Links
connection. Suggested file compression utilities include PKZip, ARJ, and
LHA.

THINGS TO WATCH OUT FOR
The following is a collection of items that may apply to your SNA Links
configuration.

When Configuring Large Networks: Using the Reliable Network Option
A feature of Novell's IPX/SPX network protocol is that all services and
shared resources on the internet advertise themselves via broadcasts. 
These broadcasts transmit service advertising data to every server in the
internetwork at regular intervals, usually every 60 seconds, even if no
change of state has taken place. 
For internetworks of 15 or more nodes, a significant percentage of the
available bandwidth may be consumed by the broadcast traffic associated
with service advertising. To minimize the broadcast traffic, SNA Links
provides a Reliable Network option.  Setting the Reliable Network option to
Yes indicates that the network is reliable and specifies that only changes
in the state of services are broadcast to the internetwork. 
When configuring large networks of 15 or more locations, you must enable
the Reliable Network option at every location.  You can access the Reliable
Networks option from the Advanced Options window in CSCON.


To enable Reliable Network options, do the following:
   1. Select the Configure SNA Links Profiles option from the SNA Links
   Configuration Options window.
       CSCON presents the Select SNA Links Profile window.
   2. Select the SNA Links Profile that you wish to upgrade.
       CSCON presents the Configure SNA Links Profile window.
   3. Select the Configuration Options option.
       CSCON presents the SNA Links Options window. 
   4. Select the Advanced Options field.
       CSCON presents the enter option window.
   5. Press <Insert>.
   6. Enter the hex value 14 in the field number field.
   7. Specify Yes in the value field.
   8. Press <Esc>.
You can continue normal procedures, or exit from CSCON at this point.  Be
sure to save the updated SNA Links Profile.

When Using RCONSOLE
When you are using RCONSOLE with NetWare SNA Links, be sure to use version
2.9 or greater.  Earlier versions of RCONSOLE may cause keystroke
turnaround problems.  Although these keystroke problems may not be apparent
at the local server, they may cause program failures when RCONSOLE is used
to access remote servers.

When Configuring Two PUs from One Server
With NetWare SNA Links and NetWare for SAA, you can configure two PUs (one
PU for SNA Links and one PU to access host applications) that share a
single multidrop SDLC link to the SNA network using a single NetWare for
SAA Synchronous Adapter. 

The two-PU/single-adapter-card configuration is not supported by the Novell
Synchronous Adapter previously sold by Novell.  If you are using a Novell
Synchronous Adapter, you must utilize a separate adapter for each PU.
When configuring two PUs for a single NetWare for SAA Synchronous Adapter,
you must do the following:
   - Assign each PU a unique control unit address.
   - Add the statement LOAD SDLCPS /M after the LOAD R3SDLC statement in
   your AUTOEXEC.NCF file.  The LOAD SDLCPS /M statement can also be
   entered manually from your NetWare system console.
   - Specify Secondary for the PU 2.1 Link Station Role parameter in your
   SDLC configuration.
   - Activate both PUs when bringing up the server. If both PUs are not
   activated, the host will continually poll for the inactive PU,
   significantly reducing the performance of the active PU.

When Configuring Token Ring Connections
When configuring a token ring connection, be sure to set the PATH
statement's CALL parameter in the VTAM/NCP definitions to the following:
CALL=IN
Page 3-7 of the NetWare SNA Links Administration Guide indicates that this
parameter is normally set to CALL = INOUT. If you set this parameter to
CALL = INOUT, you must also specify the DIALNO parameter and tune the
timeout value for each PU defined.  Failure to make these adjustments adds
unnecessary connection delays in VTAM that decrease network performance.

Using Third Party Software
An alternative to the cascaded topology is to use a mainframe based product
from Phaser Systems, the NetWare SNA Router Hub.  With the Phaser product,
IPX/SPX traffic travels from the original NetWare SNA Links server, through
the mainframe based NetWare SNA Router Hub, to the destination NetWare SNA
Links server.  This topology can provide a more constant response time when
used as an alternative to multiple cascaded topologies.  For further
information, contact Phaser Systems at 1-800-234-5799.